The present invention is directed to apparatus and method for operating a digital computer in accordance with a powerfully enhanced object-oriented programming methodology.
In object-oriented programming using existing object-oriented languages, such as, "C," and "Small Talk," programmers are able to define object "data types" (or "classes") which are data structures each associated with a program that knows how to process that data type. Object-oriented programming permits existing programs to be reused and extended without having to modify the program. This feature of object oriented programming is known as the "inheritance feature" and is the ability to define new data type classes derived as "extensions" of other (more fundamental) data classes.
The extension class only needs to define those functions (known as the object's "methods") for the new data type which differ from the existing ("base") class. Such methods may be entirely new or may supersede (by replacing or augmenting) methods defined for the base class. This simplifies the creation of novel variations of existing data classes, either by adding new functions or by superseding (modifying) existing functions.
Some object-oriented methodologies allow "multiple inheritance" whereby there can be more than one "base" class from which a given class inherits characteristics. The present invention contemplates the possible use of multiple inheritance. The lineage of a given class is the aggregate set of its base class(es) together with the base class' lineage.
Using more conventional "procedural" programming methodologies, different data types are processed in different manners based upon processing rule defined for the data type. Object-oriented programming provides a different processing methodology. Each individual occurrence of a programmer-defined object data type or class is known as an "instance" of that class. Once a class is defined, then its data type can be used over and over again in different programs with no extra programming effort.
The class program definition for each data type defines the functions that can be applied to instances of that data type. Programs use objects by invoking one of the objects methods (i.e., the functions that can be applied to instances of that data type) in conjunction with a particular instance of that object. The method then processes that particular instance of data.
Thus, one of the strengths of object-oriented programming methodology is that the same method name can be implemented differently in different data type classes. An application program can perform a "generic" operation on data without having to be concerned about exactly how it is implemented. This facilitates the addition of new varieties (classes) of data types with minimal changes, if any, to application programs using these types.
The logic to perform these "methods" is built into each data class once. In this fashion, the way in which programs use such data types is simplified by allowing different data types to each implements a particular function in a way appropriate to that data type.
Object-oriented programming thus provides a different methodology for compartmentalizing programs which is highly useful in many different complex application areas. In object-oriented programming, data is not typically treated as an isolated bitstream, but rather, it is bound to a program which manages the data.
The feature of object-oriented methodologies--the ability to have a particular function operate differently on a variety of data types--is known as "polymorphism."
Polymorphism permits a program to operate on data without being concerned with what that data represents. The polymorphic feature of object-oriented methodology permits a particular operation to be implemented in different ways depending upon the data type so that the function will be performed appropriate to that data type. An example of polymorphism may, for example, involve a "multiply" operation. For real scalar data types, two scalars are arithmetically multiplied together. But for matrix data types, the "multiply" method could be implemented to yield the more involved "matrix" multiplication. By treating these as objects, program designers can use multiplication without worrying about whether the particular operands were real numbers or matrices. Then, at some future time, for example, a new "complex" number data type with yet a different multiply mechanism could be introduced into existing programs with no further programming effort.
Another example of object-oriented methodology may involve objects associated with a graphical display. Most of such objects would have a "quick" click method that would be invoked whenever the mouse pointer lies atop the object's associated graphical image and the user clicks the mouse switch.
Consider graphical display of a group of buttons. Each "button" graphic may be represented and controlled by a separate instance of the "button" class. Other types of graphical items, such as data fields, will be controlled with instances of their own respective classes. It would be possible to treat an "icon" as a special class of "button" but one which has additional or modified characteristics.
In developing the "icon" class as an extension of "button," all of the method routines for "button" would be effective for the "icon" class, except those which are specifically supplied for the distinct "icon" class definition. Whenever the user clicks the mouse switch, the system determines the items over which the mouse appears to be positioned and invokes the "click" method for the object instance associated with that graphical item.
Different functions such as "scroll contents up," "delete this object," "print contents," or "handle mouse-button--click request" may be interpreted differently depending upon the particular graphical object involved. Allowable functions are defined when the data is defined, not each time the data is used.
The present invention is directed to significantly enhanced object-oriented programming methodologies which create a framework for efficiently performing automated business transactions. The object-oriented programming methodology of the present invention is particularly useful in the context of the applicant's "travelling program methodology" described in the above-identified Travelling Program patent application, which has been expressly incorporated in its entirety by reference herein.
A travelling program is a digital data structure which includes a sequence of instructions and associated data which has the capability of determining at least one next destination or recipient for receiving the travelling program and for transmitting itself, together with all relevant data determined by the program to the next recipient or destination. Using the methods described herein, the data is more closely bound to the program in such a way that objects may be most efficiently transferred from one computer user to another without the objects being previously known to the recipient computer user.
The present invention permits data to be structured and maintained as an object with the highest degree of security and stored and sent around from one computer user to another.
The present invention also permits application programs to be developed more efficiently than heretofore possible through the efficient creation of reusable programming pools. Using the present invention, individual objects may be transferred to other user destinations as desired.
The present invention utilizes object "cells." A cell is a data structure stored, for example, on a disk that reflects a collection of (related) objects instances whose execution has been suspended, and which can be resumed later on the same or a different platform. The collection of object instances can be gathered together into cells (or "electronic forms") suitable for storage or transmission to another computer user in such a way that instances are unambiguously bound to their respective class definition.
The present invention provides the useful capability of permitting an electronic form to be built up from arbitrary object-oriented data class components with the data class definition programs being transmitted as part of the electronic form together with the underlying object instances values.
The present invention also creates improved tools for creating and using cells (electronic forms) so that electronic forms can be defined using object-oriented techniques while allowing such forms to be easily transferred among a diverse population of computer users--without demanding that all users maintain compatible libraries of all object-class definition programs and without demanding that all users maintain identical synchronized versions of that class.
Thus, the present invention facilitates the transfer of such a cell via electronic mail to another user without concern as to whether the recipient has all the necessary object classes, or whether such classes reflect the version properly corresponding to the particular data transfer. The cells may be invoked as objects by other cells.
The invention provides a digital signature methodology to insure security and integrity, so that electronic forms (i.e., cells) composed of a collection of objects can be received and executed by a user without putting the user at risk that some of the object classes embedded in the cell might by subversive "trojan horse" programs that might steal, destroy or otherwise compromise the security or integrity of the user's system or data.
Indicia is stored in the object instances themselves to locate the associated class definition program. This includes, for example, the name of the object class instance.
Unique ways are described herein of binding data instances stored in a cell to their respective object class programs such that the correct, compatible, class definition program is assured of operating on the existing instance data when the cell is reloaded from storage when commencing subsequent execution.
This provides integrity by insuring that changed "library" or template versions of a class program cannot inadvertently operate on older instance data; or that other incorrect versions of a class program cannot be inadvertently used (and cause confusion or damage) when a cell is activated at different times by a variety of users (recipients) [even if one of the users may have a class program with a matching name]. The unambiguous binding between instance and class may be provided in a variety of ways including:
by binding an object instance in a cell to its class by including the class definition--i.e., the class program logic itself, whether it be in source, p-code or matching code--as part of the cell data structure. PA1 By binding an object instance in a cell to its class by including in the cell a [cryptographic] HASH of at least one of: the SOURCE instructions (or normalized version thereof); the pseudo-code (p-code) instructions resulting from compilation; or the machine language code resulting from compilation--for the class program definition.
The binding correlates to each instance with precisely the correct corresponding class program--so that another class with the same name, or an anachronistic version (too old or too new) of the class--cannot be inadvertently selected to operate on the existing version of instance data, when the cell is reloaded. This is especially useful for class programs that perform critical or sensitive functions. In this fashion, "master" class definitions may be changed without impairing or confusing existing instances that depend on the specification of the class definition at the time the instance was created.
In accordance with the present invention, critical portions of the cell may be digitally signed so that they cannot be accidentally or mischievously altered between the time the cell is stored and it is reused (possibly by another user). However, non-critical portions of the cell are not digitally signed so that they can be adjusted to accommodate the optional inclusion or exclusion of non-critical information, or information which can be validated in other ways. Thus, object program CLASS definitions can be stored in a digitally signed format so they cannot be corrupted. In some environments, not all object class definition programs need to be digitally signed--only the ones which perform critical operations. (Such as accessing files; or invoking external programs written in assembler language, C language, or other modules which execute outside of direct interpreter control).
Such critical portions typically include: the structure and values of the data and objects, coupled with at least un unambiguous binding to at least one compatible version of each critical object class program definition--usually including the hash value of a version of the program.
The present invention contemplates that each class can be further digitally signed in conjunction with the authorization defining the operations or functions which that class is permitted to perform. This authorization is defined by a program authorization information data structure as described in above-identified copending application U.S. Ser. No. 07/883,868 entitled "Computer System Method and Apparatus Using Program Authorization Information." This application has been expressly incorporated herein by reference.
This allows automatic detection of corrupted or malicious cells. It also provides the safety feature to insure that untrusted classes (instances) do not have the capability (either through program faults, or deliberate mischief) to cause damage. This allows means to MIX TRUSTED and UNTRUSTED classes--providing the ability to use casual instances (and classes) to supply innocuous or do limited function in conjunction with more powerful classes--assuring that the untrusted classes can do nothing surreptitiously. This also provides the capability to guard against object-oriented analogies to the Morris Internet virus/worm which was able to cause untrusted code to operate in a trusted state.
Using this methodology, the image of the class (either source, p-code, or otherwise) can be inserted or removed from the cell after it is digitally signed, without impairing the integrity of the cell.
The present invention also provides methodology so that versions of a class program are able to process instances which were created by different versions of the class program. This is done by associating with the data instance the version of the class program that created it (or last manipulated it), and by allowing each version of the class program to specify the set of data versions which it supports.
The present invention provides a methodology for repair or upgrade of an existing cell, whereby the class definition stored or referenced by the existing cell can be extracted and replaced with a revised (or corrected) definition--yet without sacrificing integrity even if the cell has been digitally signed.
It provides a methodology whereby one cell (electronic form), composed of a variety of objects, can be stored and restored to execution on the same or other computers.
It permits entire cells themselves to be invoked and processed as objects by other cells. This allows the cross-merging of data and processing from cell to cell; and the means for handling complex systems of cells in which the cell themselves interact. It permits cells to cause their own transmission from user to user through the use of electronic mail or other services. It allows the inclusion of cells within other cells, as well as the ability of a cell to later re-separate interior cells. The invention also allows an isolated portion of its interior objects to be isolated and used to create a subcell.
The invention teaches how various classes to be written different languages (such as "BASIC" and "REXX," for example) can yet be combined into a common object cell. The invention teaches how disparate languages, such as REXX and BASIC can be combined so that a class defined using one programming language can be extended from a class written in another language.
In another aspect of the invention, programs can create, process and manipulate objects for which either the class, the methods, or both, are dynamically determined independently (and after) either the specification or compilation of the program. This is possible because both the class and method names are controlled by string values, which permits them to be dynamically determined based on any inputs, decision and string manipulations.
Therefore, objects may be created based strictly on names--which may be entered as data by a user, computed dynamically based on run time values, or read from a file. Another aspect of the invention is that class binding is performed at execution time as they are used--so that no special "linkage editing" step is required to bind various classes into an "executable" module.
The present invention advantageously permits object oriented programs to be combined with travelling programs to allow travelling programs to be constructed using object oriented techniques. It permits travelling programs to be processed as objects themselves [by other travelling programs].
The present invention permits digital signatures to be used with travelling objects so that associated class [program] definitions cannot be corrupted, manipulated, or altered in definition. It permits digital signature technology to be used for security and integrity purposes to limit the computer and data resources that can be processed by instances of particular object classes, and the type of processing that can be done.
It permits a network of computer users to exchange data containing a plurality of object instances such that:
the recipient can safely perform at least one of the methods in the transmitted object instances, without danger of malicious damage or compromise of the recipient's data.
One of the features of this invention is the ability to develop programs in which data variables are not inherently bound to a particular object class. The present invention allows a programmer to develop programs in which the class of variables can be freely changed during the execution of the program to reflect any object class--even those which were not contemplated at the time the program was written.
Another feature of this programming invention is the ability for different instances of the same object to possess substantially different sets of associated data fields.
Another feature of this invention is the ability whereby a collection of mutually associated instances, typically associated with several classes, can be written from their execution state into a saved data file; this is done in such a way that the programs which define the instances' classes are themselves unambiguously bound into the saved data file. In this invention, such a saved data file shall be called a "cell."
This invention allows the proper reloading of a cell so that all instances, data associated with the instances, and the programs associated with the instances are recovered with full fidelity so that execution processing of the overall cell can commence at some future time.
A feature of this invention is that the cell can be treated as an object itself, so that the execution state associated with the cell at the time of its saving can be invoked at some late time.
In the present embodiment of the invention, in each cell there is one particular object instance which is considered the "face" of the cell. Whenever a request is made to a cell to perform a method, it is the method of the face instance which is activated. Hence, whereas a cell may contain many constituent instances, it is the face instance which is responsible for handling requests for overall cell activity.
It is a feature of this invention that the language in which the classes are defined is not specific to one computer type, and that it may be processed or interpreted across a broad range of different computer architectures and operating systems.
It is a feature of the invention that the actual logic defining the object classes may be stored in and carried as part of a stored cell. This serves at least two benefits:
the cell retains integrity even if the associated class-defining program is changed. In other art, where the class-definition is only loosely coupled to its instances, it is dangerous to ever change (or "improve") the program, since such changes may give different meaning to existing data variables, introduce new variables, or eliminate old variables--in such a way that processing "old" data with the new program is apt to yield program dysfunction or incorrect and misleading results.
This allows the cell to be transmitted to another computer and executed there without concern for whether:
the class-defining program is available on the other computer;
whether the reference class-programs as found on the recipient's computer are compatible with the data instances as built within the cell.
It is a feature of the invention that the logic of at least one of the associated class definitions may be uniquely identified in the stored cell by the hash of the associated program. This serves different purposes than storing the program definition itself:
It allows cells to be stored in smaller space without duplicating the class program in each cell, yet still insures exact integrity without storing an image of the program. This is accomplished during cell reload, when the actual hash is recomputed and compared with the expected hash.
This insures that no software changes (deliberate, accidental, or malicious) can inadvertently lead to misexecution, yet it does not demand the storage overhead of duplicating copies of frequently used classes repeatedly in many cells.
For commonly used classes, such as those which may be widely distributed through a given enterprise, it is reasonable to suppress transmission of the program itself--yet the hashes of the class programs are valuable to insure integrity by preventing a wrong class program from even being used. Whenever a class program is loaded, its hash is computed and compared with its expected value.
If a cell does not contain the class definition image, and there is no image available at reload that agrees with the hash, then the hash can be used to locate the correct class definition and to confirm correctness when found. This strategy is effective even if the correct definition is recovered from offline, archived storage. Once all the correct class definitions are recovered and made available online, then re-execution of the cell can commence.